BMUG Revelations

home *** CD-ROM | disk | FTP | other *** search

/ BMUG Revelations / BMUG Revelations.toast / Business / Random / PC to Mac Conversion / PC2MAC.ASC next >

Wrap

Text File | 1992-02-15 | 79KB | 1,723 lines

PC TO MAC CONVERSIONS ===================== Basic Conversions from a DOS Viewpoint -------------------------------------- By Nancy Jacobsen (Presented at Fox Software Developers Conference, October 1990. Updated thereafter.) I. INTRODUCTION =============== "FoxBASE+ applications from DOS must work immediately and perfectly under FoxBASE+/Mac -- no sweat, no excuses." -- Fox Software, FoxBASE+/Mac Users Guide The above quote is Fox Software's statement of philosophy about running DOS programs on a Macintosh. As a philosophy this is admirable, and, in my opinion, sincere -- unfortunately, it is not necessarily *true* in practice. It *can* be true, but I'd guess that any reasonably sophisticated, complicated, or lengthy program developed in DOS will run into at least a few problems when ported to the Mac. In all fairness, given the complexity of moving a program between two such diverse platforms, I think that Fox has done an outstanding job. Just to be able to do it at all... and the fact that, indeed, most of a DOS program ports unchanged is quite an achievement. Right up front, I want to say that this presentation does not deal with advanced, or even advanced intermediate, Mac interface issues, such as event driven programming and interface design elements. This presentation is concentrated on the basics -- how to move a program over to the Mac with the least amount of hassle and the best possible results in the prevailing circumstances. A. Purpose of this Presentation ------------------------------- This presentation has two main purposes: * To provide a logistical framework which will help you plan a basic conversion from an existing FoxBASE+ MSDOS program to a Macintosh program. When I started out, I didn't really know enough about the Macintosh or PC to Macintosh conversions to actually plan my conversion. I ended up making many decisions out of last minute necessity rather than as part of some pre-defined plan of action. However, I think it would have helped if I'd had some guidelines, especially with regard to reaching a reasonable stopping point. * To provide detailed information on the mechanics of moving a program to the Mac, including how to handle certain, relatively small, problems which can otherwise drive a person crazy. Details like this may be, frankly, a little boring, although knowing about them in advance can save you a lot of time, possibly a very great deal of time. I have tried to include everything I wish *I'd* known when I started out. 1. Point of View ---------------- When the Mac first came out, or rather, I suppose the Lisa, I was very curious about it since it could do so many interesting things, especially with graphics and desk top publishing. However, I couldn't justify the cost and, in time, similar programs were developed for the PC which were totally adequate for my needs. Not only was I very DOS oriented, but I knew how hard it is sometimes to adapt to a new machine -- even so apparently simple a matter as a new keyboard can cause great frustration. So I was very reluctant to consider porting my existing application to the Macintosh. However, I produce a vertical market application for newspapers and other publications. A lot of these businesses are moving entirely to Macs, driven by the desk top publishing features, and naturally many want to deal with only one kind of hardware. Although I was resisting, a move to the Mac was looming. As usual, I finally made the effort when someone paid me extra up front to figure it out. In the past few years, the Mac has gained more and more of a footing in the business world. Although, from a DOS viewpoint, we may never really want to develop for Mac, it is beginning to make sense economically to port existing PC applications to it, especially since Fox makes it relatively easy. I still am not particularly comfortable or thrilled with the Mac. I use it only for the Mac version of my software. There have been times when I was so frustrated I could have kicked it across the room. For those of you who are DOS people, you should know that not everyone loves the Mac and, indeed, you don't have to. And some of you *will* love it. For those of you who are "coming from" a Mac background and think whatever you think about DOS, this presentation may help you to understand that certain people don't love the Mac like you do and can get cranky about it. Their reasons aren't totally without merit. Neither are yours for your Mac preference. With any luck, there's room for both points of view. 2. Personal and Project Background ---------------------------------- Obviously, where I was coming from in terms of personal experience and the nature of the conversion project at hand affected what in fact got done and colored my experience of the affair. At the time, I had 7 years of CP/M and DOS experience. I had *no* Mac experience except for some similar interfaces like GEM (Ventura) and various DOS paint and draw programs. So I knew a little about scrolling and mousing, but not a lot. With all that's written about how *easy* the Mac is to operate, I was surprised and somewhat dismayed to discover how much there was to learn. Quite a few things seemed very tedious and cumbersome to me. They still do. My resources were limited. I didn't have a lot of time and I had a deadline looming (the sad byproduct of up front motivation). I didn't have a lot of money, but I had to buy a Mac and the Mac Fox products, plus all the little incidentals like disks and disk boxes. I didn't even have space to put the Mac when I got it. Eventually it settled down but only after a massive reorganization. And, finally, my brain was pretty thoroughly occupied already. It's hard to tackle this kind of project when there are a lot of distractions. The project itself was a problem. It was originally written in dBASE II six years previously by another programmer so there were still pockets of code that I didn't understand. It was big -- 1.7 megabytes of compiled code, about 40,000 lines. It was single- and multi- user. It was accounting software so that any changes needed to be made very carefully and thoroughly tested. And, finally, it needed to work on a wide variety of hardware -- from the low end up on either Mac or PC. II. LOGISTICAL FRAMEWORK ======================== A. How Mac to Make It? ---------------------- "But, obviously, nobody wants to run applications on the Mac that look like DOS applications." -- Fox Software, FoxBASE+/Mac Users Guide. Normally, I would say "Don't get me started on this," but I'm being paid here to get started on this. For the moment, let's just say with regard to the discussion at hand, that it wasn't obvious to *me*, and that for a lot of practical reasons, running a program on a Mac that looks like DOS may be *necessary*, at least in the short term. Indeed, the fundamental question you need to ask in a PC to Mac conversion is "How Mac to Make it?" The answer to this question is based on an analysis of interrelated factors which combine to affect the amount of resources (work and expense) that will be required for a proposed conversion. These in turn must be weighed against the resources that are *available*. Based on your conclusions, you should have at least a rough idea how to proceed, including having answers to such questions as: * How Mac to Make It? -- including How Mac *can* I make it?; What can be done now or in the short term? What can or should be postponed until later? * Should I proceed at all? -- any PC to Mac conversion is going to require at least a certain amount of work. If one of the factors described later requires a great deal of work, and your resources are severely limited, a conversion may not be practical. * Should I try to maintain one program which can be transferred to the Mac or should I maintain two separate versions? B. Decision Factors ------------------- There are three main factors that affect the quantity of resources that will be required to convert a PC program to the Mac. Aspects of all these factors will be covered throughout this presentation, but to summarize, these factors are: * How Mac to you want or need the program to be? * How PC is the program now? Indeed, how PC are *you* now? * How large, how complex and how volatile is the program? As a rule of thumb, a small- to medium- sized, plain vanilla PC program that looks a *lot* like DOS on the Mac will be a fairly easy project. As a program gets bigger, more complex, uses more PC specific features, and looks more and more Mac-like, the harder the project's going to be. 1. How Mac do want or need the program to be? --------------------------------------------- The Mac interface is quite different from the PC interface, not only visually but in what it allows a user to do. Visually, the Mac emphasizes pull down menus, windows, radio buttons, dialogue boxes, alerts, fancy fonts, and a wealth of other features not available on DOS in FoxBASE+. The interface also tends to allow users more flexibility in what they're doing at any point in time, for instance, interrupting one task to do something else. FoxBASE+/Mac supports these features on the Mac, but it does so by using commands and command options that do not exist in FoxBASE+/PC. Consequently, installing all these features in an existing program can be very, very time consuming. However, installing *some* of these features isn't too hard. How do you know how Mac you want or need it to be (and consequently how much work is involved)? You should be aware that Apple is pretty picky about the Mac interface. Their point is to make all Mac applications behave in approximately the same way to make it easier for users. In the Mac world there are certain people, sometimes referred to as the "interface police," who come down pretty hard on any application that doesn't adhere strictly to Apple's interface design guidelines -- especially an application that looks like DOS in anyway. (You can get a sense of their attitude from miscellaneous comments around the FoxBASE+/Mac documentation.) Software dealers can be particularly nasty about this and may reject your application on this basis alone -- no matter how useful it is. On the other hand, the end users of an application may not care too much, if at all, and, in some cases, may even like a few DOS-like features. Usually the end user's primary concern is whether an application will get the job done. You might also consider *how* an application will be used. If the application is one that is used all the time and intensively, it's consistency with other Mac programs is not as important. However, if it's used occasionally as one of many Mac programs, consistency becomes more desirable. So, you need to look at the nature of your product and who you're selling it to. If it's a generic type of application that will be used occasionally by end users and is sold primarily through dealers, a greater degree of Mac interface compatibility is desirable. However, if it's a vertical market application that will be used a lot by the end user, and is marketed directly *to* the end user, a greater amount of interface flexibility is possible. 2. How PC is the program now? How PC are *you*? ----------------------------------------------- Since Fox did such a good job of ensuring Mac compatibility, the current PC-ness factor is the least burdensome of the three factors we need to consider. However, it can trip you up if you've written a *lot* of very PC-specific code. The three main areas to watch out for are: * Extended characters -- the MSDOS extended character set is different and more comprehensive than the Mac extended character set. Line and box drawing characters, in particular, can be a problem because there are no Mac equivalents. In fact there are no Mac equivalents for a great many of the DOS extended characters. If you use extended characters a lot, watch out. Related to this issue is that functions like INKEY() may return different values than they do on the PC. * Non-supported commands and functions -- Although FoxBASE+/Mac supports the vast majority of FoxBASE+/DOS commands and functions, it does not support them all. If you are unfortunate enough, say, to have an application that uses the RUN command 500 times, you'll need to do some major rethinking. I *did* have a module like that and I *still* haven't dealt with the issue. * Printing -- the Mac prints things differently than DOS does. Certain printing tasks (ones you don't even think about with DOS), like printing a sample form to allow forms alignment, take some tricks to achieve on the Mac. How PC are *you*? If you've been doing DOS for awhile and you're comfortable with DOS commands and the way DOS programs work, it is going to take awhile to learn and adapt to the Mac way of doing things. A lot of Mac stuff seems unbearably tedious to me (point and click, point and click, *point and click*) and some simple tasks are hard to do (like copying files). It helps if you have some familiarity with graphic interfaces on the PC (like GEM or the paint and draw programs), but one way or another, you'll have some adjustments to make. 3. How large, how complex, and how volatile is the program? ----------------------------------------------------------- * How large? It's pretty obvious that 30,000 lines of code is going to take longer to convert than 1,000 lines of code -- just the file transfer time is going to be longer, if nothing else. If you've got 30,000 lines of code and want to make the application totally Mac, you've got a whopper of a project ahead of you. * How complex? A complex program is *always* harder to change and maintain. So, basically any changes of any kind that are required by a Mac conversion will take some careful consideration. More than that, if you go the whole Mac route and start incorporating event driven programming and the like, this area will get *very* complicated, *very* quickly with *very* serious (and not always obvious) consequences if you do it wrong. * How volatile? How much and how often does the program change? This factor addresses the longer term implications of converting to Mac, as well as how Mac to make it. Basically, do you want to develop one application that can be used interchangeably on both platforms or do you want to maintain two completely separate versions? If you have a program that is changed a lot and/or has large changes (lots of new features, for example), it would be a lot easier if it could be maintained on one platform and then ported over to the other. In this case, the same code would need to accommodate both Mac and DOS conditions. The more Mac you make it, the harder this is to do and the larger the code becomes ("if DOS, do this menu, otherwise do that menu"). Moreover, Mac data entry screens, for example, especially those using fancy fonts and buttons, are very difficult to design without using the Mac screen designer. This means that you'd have to design a screen on the PC, then design it again on the Mac, and then transfer the code to the master program. What a headache! Although I think this will get easier with future Fox releases. But, unless the Mac specific code causes your program to become very large, one version should be easier to maintain than trying to maintain two separate versions. If you *do* decide on separate versions, be sure to debug your PC program as thoroughly as possible before making the conversion. C. Available Resources ---------------------- Once you've got an approximate idea of the resources you're going to need, you've got to look at what resources you've *got*. A Mac conversion is going to take: * Time -- Learning time. Programming time. Testing time -- I tested *everything* all over again on the Mac and it was a very good thing I did. Documentation time. Do *not* expect to complete a Mac conversion before you go on vacation in two weeks -- give yourself plenty of leeway. * Money -- Hardware and software. Training. New documentation printing costs. Disks and disk labels. You also need to consider the possibility of engaging others to do some of the work. I say if you've got the money, hire a FoxBASE+/Mac expert to do the conversion and maintain the program, but if you don't, you may still be able to parcel out some of the tasks. In my case I originally teamed up with just such a person and he handled all the initial things like physically moving it to the Mac and figuring out some of the programming tricks. But I still had to do all of the testing, and eventually it got easier to just change things myself rather than having him do it. I don't regret doing it this way. Although, in the end, I had to learn it all anyway, a lot of the things he did would have taken me a very long time to figure out by myself. Moreover, when I *did* have to learn it, it was much easier to work from something that was already started. Finally, being a Mac novice, I was glad for a little hand holding at the beginning. * Space -- A simple thing, perhaps, but I had a real problem figuring out where to put the Mac. It ended up on the dining room table until Christmas dinner, moved into my husband's office, and finally came to rest in my own office (after a substantial amount of reorganization). * Brain Power -- We're all smart -- that's why we're here right now -- but, face it, we all have limits and a Mac conversion requires *attention*. Try to clear the decks of other projects before you start so you can concentrate, and keep distractions to a minimum. D. Scope of Presentation ------------------------ This presentation is going to concentrate on the low end: a very basic conversion. I'll start by covering the mechanics of just getting an application over to the Mac and working. Then I'll throw in some hints for making an application as Mac-like as possible with as little work as possible. There's a lot of fairly easy stuff that can make a nice difference. The result will not pass an interface police raid, but it will work. My approach will work pretty well for large, complicated and volatile programs, and for developers, especially the single person shop, without a lot of resources. I will, for the most part, be leaving out advanced Mac features, especially those which are not supported in DOS and aren't backwardly compatible. III. BASIC CONSIDERATIONS ========================= In this section we'll deal with the basics of just getting a program over to the Mac and working, with a few hints on easy ways to achieve a Mac-like look. The points I cover here will affect your conversion plans and resource requirements. A. Equipment ------------ You'll need a Mac, of course. And you need to learn how to use it. Here, for the benefit of the complete Mac novice, I'll briefly share some things I learned that were really useful. * In general I would say get the best Mac you can afford, but if you want to keep developing on the PC and the Mac will not be used very often, you probably don't need a II. An SE or even a Plus should work fine. (However, I read recently that these two will be phased out with the introduction of the low-end Macs.) Also don't forget that all Macs are not alike. If you're developing applications that you want to run on any Mac, you may have to identify the lowest common denominator. I've got one: Mac Plus -- small screen, no function keys, no help key, no escape key, 800K floppy drive. Actually, this machine works fine for me except for one thing. Although I have 2.5 megabytes of RAM, editing large files is *extremely* slow. I can press a key and literally sit back and wait for it to type. * RAM -- Fox tech support says that monochrome Macs require 840K of free RAM, a color Mac needs 1.2M of free RAM (without Multi- finder). If you or one of your users loads a lot of desk accessories on a machine, 1 megabyte of RAM on a monochrome system may not be enough. Keep in mind that Apple is working on a new version of its operating system (System 7) which is supposed to take more memory when, if ever, it is released. * Immediately get a program like Mac Tools Deluxe (formerly PC Tools for the Mac). This program contains an easy file copy program (including being able to make multiple copies of floppy disks for distribution -- invaluable), a backup program, data recovery features and other useful things. Copying files is a hassle on the Mac (*moving* files is easy), but Mac Tools works great for this. * Learn the keyboard shortcuts! Continuously pointing at menus with the mouse and *pulling* them down is really tedious. However, most programs have at least some keyboard shortcuts which usually mean pressing a combination of the Command key and a letter. Not only is a lot of mousing often tedious, but it can sometimes make your wrists hurt like heck. Change your mouse hand from time to time and take lots of Vitamin B-6. Update note: There's a program called Quickeys by CE softare that allows you create keyboard macros to replace a lot of the mouse stuff. I haven't tried it, but it sounds great. * If all those icons are driving you crazy, select View by Name from the desktop menu. B. Physical Transfer of Files ----------------------------- I'm not going to spend a lot of time on this. There are a number of ways to physically transfer files from the PC to the Mac (your hardware dealer should be able to help you): * Outside Conversion and/or Floppy Disks -- There are many service companies that will transfer data from PC disks to Mac disks. Also, some Macs can read PC formatted 3 1/2 inch floppy disks either with an internal floppy drive or an external device. I'd say this latter method is only practical if you personally have both a Mac that can do this and a PC that writes to 3 1/2 inch disks. Otherwise, the additional cost and inconvenience of using a conversion service to transfer files to a Mac floppy would almost certainly justify the purchase of an inexpensive serial data link program. * Serial Data Links -- There are several serial data link programs which can be used to transfer files. These programs connect a Mac to a PC with a cable. I use Laplink Mac III and have been very happy with it. It not only allows me to transfer PC programs to the Mac, but allows me to transfer files back to the PC (for instance, screen shots for documentation). The program is inexpensive, easy to use, and comes complete with all the cables and connectors you'll need. If your PC and your Mac both have modems, you can use modem communications software to transfer the files, but Laplink Mac, for instance, uses a much higher transfer rate (115,200 baud). * Networks -- If you can afford a network to connect your PC's and Macs together, then use one to transfer your data. A little too expensive and complicated for the smaller developer, perhaps. C. Compatibility ---------------- FoxBASE+/Mac is compatible with all FoxBASE+/PC files: programs, databases, index files, memo files, format files, label definition files, report format files and memory variable files except: * Compiled (.FOX) files: These will not run on a Mac. Transfer your .PRG files to the Mac and re-compile them. * Program (.PRG) files: A few commands and functions in the program files are unsupported, and you'll find a few other inconsistencies (discussed later). * dBASE III Index (.NDX) files: need to be converted to Fox index format. Fox .IDX files are fine. * Report format (.FRM) files: FoxBASE+/Mac documentation says that a report which is 132 characters long will require some modification in the Mac product. I don't know why and didn't try it. * Memory variable (.MEM) files: screen-type memory variables (SAVE SCREEN TO var) are not compatible. * DOS batch (.BAT) files are, of course, not supported and there doesn't seem to be any real equivalent. Too bad, in my opinion. 1. Miscellaneous ---------------- On DOS machines each line in a text file is terminated by a carriage return followed by a line feed. Macs use only a carriage return. So programs should be transferred to the Mac with the line feed stripped out. Lap Link III will do this for you. All other files should be transferred "as is" in binary format. Mac files keep track of which application created them. When programs and other files initially get to the Mac, they haven't been flagged with this information yet, and won't be until they've been used. This means that when you're trying to open a file or do a program that hasn't been flagged yet, it won't show up in FoxBASE+/Mac's file finder dialogue boxes. You can, however, click on the All Files check box and select the desired file from there. Mac program files are quite different than FoxBASE+/PC program files: the source code and compiled code are kept together all in the same file. I personally find this very annoying. For one thing it takes up tons of disk space. For runtime distribution, you can strip out the source code, but you can never strip out the compiled side. What's more every time you edit a program file, the whole thing compiles again (actually, you can turn this off temporarily, but it will compile again when the program runs). If your procedure files are really large, this can take quite awhile and quickly becomes very tedious. Basically, this is another topic that you shouldn't get me started on. However, one quick way to make sure your programs can be found by the Fox file finder dialogues is to immediately compile them all once they've been transferred using the COMPILE options (look this up in the manuals). When you're editing and compiling automatically, FoxBASE+/Mac will flag errors and transfer you to the edit window for corrections. This does not happen when you use a COMPILE option. If you want to catch possible compilation errors, edit and save each program. I also think it would be wise to immediately reindex all database files. It didn't happen very often, but both myself and one of my users (who transferred files from a PC) lost index files. I don't know why this happened but I think if they are reindexed on the Mac it might prevent it. Program Naming -- You can take advantage of Mac file names (more about this later) by renaming your applications so they are more descriptive. For instance, my program is called DISPLAY/390. In DOS I had to refer to it as D390 or DISPLAY, but on the Mac, I renamed it to ".DISPLAY/390". Why the initial period? My program has a lot of procedure files and they all get lumped into the same folder, usually along with FoxBASE+/Mac, several data folders, and miscellaneous .MEM files. One nice thing about DOS is that batch files can really shelter users from all your program and miscellaneous files -- they don't see them unless they do a directory. With the Mac, the user sees *all* the files in the folder. You can use a utility like Mac Tools to hide the ones you don't want visible, but for support purposes, it's sometimes helps if you can have the user tell you what files are there. Not only does the user see all the files, but they can be displayed by icon which is very confusing with a lot of files. So what I do is to name my application so that it alphabetizes at the beginning of the file list and have users set the desktop view to "VIEW BY NAME". I also include a little separator file named "=========" that divides the programs they're supposed to use from the procedures that they shouldn't touch. The value of this is that a user can run your program by double clicking on the program -- which is now easily accessible at the top of the list. D. Program Initializing Code ---------------------------- In your master program, if you're hoping to develop one program that will run on both machines, while your setting up your environment, establishing public variables, etc., you'll want to establish a public variable to indicate whether the program is running on a Mac or not plus various other initialization routines for the Mac or PC, depending. Examples of this kind of code are included in the sample program and also discussed later. To establish whether the program is running on a Mac, use the SYS(17) function: PUBLIC mmac mmac=.f. IF SYS(17)='68000' .OR. SYS(17)='68010' .OR. SYS(17)='68020' ; .OR. SYS(17)='68030' mmac=.t. ENDIF From now on when you need to make logic branches depending on whether the program is running on the Mac, you can use: IF mmac DO this ELSE DO theother ENDIF E. File naming -------------- File naming is covered pretty thoroughly in the User's Guide and I'll basically leave it to you to figure it out (this may not be easy, I still have trouble with this one). However, let me share one or two things that I've learned. 1. Macintosh File/Folder Names ------------------------------ What we call sub-directories on the PC, the Mac calls folders -- basically they're the same kind of animal. The Mac uses colons to separate the folder and file names whereas the PC uses backslashes. (For example, the Mac equivalent of C:\DATA\ACCOUNT.DBF would be C:DATA:ACCOUNT.DBF). Mac folder and file names can be quite lengthy and contain almost any characters including spaces. There are several consequences to this: * The most important, and the one that causes the most trouble for the DOS person, is that any Mac folder/file names that contain or *may* contain spaces, must be enclosed in quotation marks (except sometimes -- see SET PATH). So, if for instance you are using a macro to designate path names, say &FLE.DATA.DBF, you will need to use "&FLE.DATA.DBF". If you add the quotes to your DOS code, it will run just fine. * If you allow users to enter a path/folder name (say upon installation) to tell the program where files are located, you may need to increase the size of the variable to accommodate longer names. Similarly if you provide a mask in the form "C:\ \", you will want to change that for Mac users (I found it was easiest simply to eliminate the mask altogether on the Mac). * If your program looks for backslashes in path names for any reason, you may need to change that too for use on the Mac. 2. File Name Translation ------------------------ As you'll see in the User's Guide, FoxBASE+/Mac has several ways of dealing with path and file name translation which can be helpful to you depending on how your code is written now. * Dos Filename Conversion -- If you have hardcoded all your path/file names, the Mac will automatically translate them to the Mac. So if you refer specifically to a file C:\DATA\CUSTOMER.DBF, the Mac should handle this just fine, *as long as* you have a hard drive called "C", and a folder called "DATA" on your Mac. There are some pitfalls to this, check out the User's Guide carefully. To avoid any confusion during filename conversion, always refer to files by their fully specified pathname. * Set Volume To -- This is a really neat option *if* you refer to files by drive designation only, for example C:ACCOUNT.DBF, which you may do if you have an application left over from double floppy days. Unfortunately, neither FoxBASE+/PC nor Foxpro/PC (1.02) support this command (it would be a very handy feature if they did) so it doesn't help you maintain one program for both platforms. * Set Path -- This operates in a mysterious way. As far as I can tell, you *do not* use quotes around the path, even if a folder name contains spaces. If your path is stored in a macro, don't place quotes around this either. The easiest way to figure out what to use is to use the View window to set the path and then see what shows up in the Command window. * Macros -- These work just fine, just be sure to enclose them all in quotes (except for use with SET PATH). F. Unsupported Commands and Functions ------------------------------------- Here's a list of commands and functions not supported in FoxBASE+/Mac 2.01. Commands and functions that are ignored need not be commented out -- they simply produce no effect. RUN -- use of this will produce an error "Feature not supported." DISPLAY HISTORY -- ignored, but if sent from the command window, it activates the screen while others have no effect at all -- I'd comment this out where it occurs to avoid possible problems. LIST HISTORY -- ignored SET COLOR ON/OFF -- ignored SET DEBUG ON/OFF -- ignored SET DELIMITERS ON/OFF -- ignored SET DELIMITERS TO -- ignored SET HISTORY ON/OFF -- ignored SET HISTORY TO -- ignored SET MENU ON/OFF -- ignored SET MESSAGE TO -- ignored GETENV() -- will be ignored, but it will catch and report an error if you use it wrong (e.g. GETENV(13))! SYS(13) -- This always returns "ready" no matter what the printer status. SYS(2000) -- ignored SYS(2001) -- ignored SYS(2002) -- ignored SYS(2003) -- ignored 1. Undocumented Commands ------------------------ Interface No-No's In some documentation you may see that the following commands are not supported, although they are. In general they are supported reluctantly, being considered by the interface police to be "inappropriate" to the Mac environment, but they're supported well and will save you a lot of time if they're left alone. They are included in the Mac command set so reluctantly that they aren't included in the on line help file or the manuals. @...MENU / READ MENU TO @...PROMPT / MENU TO READ MENU BAR TO @...BOX ACCEPT .. TO SET STATUS ON/OFF 2. Other Commands ----------------- The following command was at one time reported as unsupported, but it is. LOAD/CALL/RELEASE MODULE G. ASCII and Key Support ------------------------ Since the Mac and PC ASCII codes are different, this naturally will affect any code that relies on a PC ASCII code that doesn't exist on the Mac. Mac ASCII codes only go up to 216 while PC goes up to 255 and they do not always have equivalent values. Related to this is that the PC has many more keys than simpler Mac keyboards. I've never seen an extended Mac keyboard, but my Plus doesn't have the following commonly used keys: ESCAPE (which can be emulated with Command Period), HOME, END, PGDN, PGUP, INSERT, DEL, or FUNCTION KEYS. When you are trapping key presses, you will have to bear these facts in mind and make adjustments as necessary. For instance, the ON KEY = command and the INKEY() function are both affected. The READKEY() keycode values appear to be identical for both the Mac and the PC, where equivalent keys exist. Another thing to be wary of is the use of ASCII characters to place markers in fields or variables. If you routinely use something like CHR(255) as a marker, you'll need to change this. Function keys don't exist on all Mac keyboards. On some machines (not the Plus) they can be emulated by pressing the Command key and a number, e.g. Command 1 = Function Key 1. Any SET FUNCTION # TO X command should work with this setup. However, there are no key code values for command/number combinations so it is not possible to use the ON KEY command with function keys on these machines. Trying to write generic code to run under all these varied conditions is a little difficult. I was hoping that I'd be able to use the FKMAX() function to check for function key availability or equivalents. Unfortunately, on my Plus this returned a value of 12 -- even though there were no function keys available in any form -- not helpful. H. Screens ---------- For the most part, DOS program screens translate directly to the Macintosh. However, with a little attention to screens, you can introduce a pleasant degree of Mac-ness without much bother. Further attention needs to be paid to a few DOS commands that can cause trouble on the Mac, and, if your DOS program uses a lot of boxes and extended characters, you may need to resolve some problems with the way the Macintosh handles these items. 1. Basic Screen Characteristics ------------------------------- If you run a PC application on the Mac, the FoxBASE+/Mac uses screen defaults that will accommodate your application -- that is, it uses, for instance, a font that will show 80 columns on the screen. But, although you don't really have to do anything to make a program run, screens are such a basic element of the Mac, that it's a good idea to figure them out, even if you keep them simple. According to the manual, FoxBASE+/Mac has nine available screens in which input and output can be performed. However, for easy porting of a DOS application, you will need to be concerned with only one, and it's easiest to make this Screen 1 which is the default. In the initializing portion of your code, you will need to establish the characteristics of this screen which you do using the SCREEN command. Here's an example of a basic screen command: SCREEN TYPE 8 AT 0,0 FONT "Monaco", 9 HEADING "Program Title" ; LOCK Since we are dealing with default Screen 1, the screen number has been omitted. If you are creating other screens, you will need to add the screen number to the command, e.g.: SCREEN 2 TYPE 4 FONT "Geneva",12 TYPE -- There are six screen types which feature different combinations of features (zoom, close, resize, etc.) and borders. Type 8 (the default) is a very Mac-like screen type. Types 8, 4 and 16 allow you to place a title on the screen which looks very nice. These types can also be moved. Types 1, 2 and 3 cannot be moved, resized, zoomed or closed, and they do not allow for titles. The ability to resize or zoom a screen is probably immaterial to a basic DOS conversion; however it is nice to give the user a chance to move the screen if desired (especially if the user is using a larger Mac monitor). AT -- This option allows you to position the screen. If you omit this option, the Mac positions the screen in the upper left corner of the monitor. Mostly, you won't need to care about this except that the "0,0" option will center (vertically and horizontally) the screen on the monitor. This is pleasing on the small Mac monitor for those who appreciate symmetry and could be quite dramatic on a larger monitor. FONT -- For quick conversion of a DOS program to the Mac, you should choose a fixed-width screen font in an appropriate size. If your program will be distributed to users with a variety of Macs, you should also choose one that is common to all machines and fits on the smallest Mac screen. Two fonts that meet these needs are 9 point Monaco (the default) and 10 point Courier. I prefer Monaco since it seems easier to read. Most of the screen examples used here, except for examples using the IBMKlone font, use Monaco. The IBMKlone Font is based on Courier. The IBMKlone Font, a shareware font that comes with FoxBASE+/Mac, is also available and may be the font of choice for some applications. However, this font has some problems and is not really recommended. When I tried calling the developer, he'd moved and did not return my call. I've heard that there are other fonts that emulate DOS, but don't personally know of one. If you are running your program on a Mac with a larger monitor, or if you never use the full 80 column DOS screen width, you may be able to use a font in a larger point size or a bold version of the same font size. The name of the font should be enclosed in quotes followed by a comma and point size: FONT "Monaco",9 Important note: If you are not printing directly to the COM port (for reasons explained in the Printing section), your printed output will be in the same font and size as your screen font. If you are using 9 point Monaco, this means that your reports will not take up the entire width of the page. Consequently, you may want to change the screen font before printing jobs (and change it back before returning to screen output). More on this when we get to printing. HEADING -- This option places a title at the top of the screen for screen types 8, 4 and 16. You can use your program name or the names of procedures. This is a simple way of making your program look more Mac-like. The title should be enclosed in quotes: HEADING "Program Name LOCK -- This is important when using screen types 8, 4 or 16 which normally allow the user to close the screen by clicking on the close box. If this happens during the normal use of a DOS converted program ("Gee, what happens if I click this box?"), the screen disappears and can't be retrieved, though it may reappear if the program encounters another screen command! Input can still be carried out, but can't be seen, so the user simply has to muddle through and hope to find a way out of the program. Note: Whenever you issue a SCREEN command (say to change the screen font) always issue the LOCK command at the same time to avoid this problem. You'll see examples of this in the sample program. 2. Color -------- I don't have a color Mac so I don't know what happens with SET COLOR TO commands on them. I'd hope that they'd translate directly. However, the colors you've developed for the PC may not be similar to Mac color standards. You may need to check out some color Mac programs and see what they use. On the monochrome Mac, the operation of color commands is a little more complicated. If you were smart enough to use macros for colors on the PC (and guess who wasn't), shifting to the Mac shouldn't be too problematical. An example of the code for this is included in the sample program. If, on the other hand, you have lots of specific SET COLOR TO commands, it's kind of a headache. First, it appears that *any* kind of SET COLOR TO [something] command will disable bar highlights in @...PROMPT menus on monochrome Macs. If you have @...PROMPT menus, about the only thing you can do is to retroactively use macros or comment out all SET COLOR TO commands. Second, some SET COLOR TO commands have a weird affect on GETS. The effect on GETS is terribly confusing. The monochrome Mac appears to ignore all color pair settings except those with a standard foreground of "W" ("W+" is okay). And it appears to ignore any enhanced color pair sets. For example both the following commands will SAY *and* GET black text on white SET COLOR TO B/N,N/W SET COLOR TO W+/B,W/N Both the following commands will SAY *and* GET white text on black and any CLEAR command issued with these color settings will clear the screen black: SET COLOR TO W/N,N/W SET COLOR TO W/B,W/N The easiest way of dealing with this problem is simply to change all occurrences of W/? to something else. If you *want* to have white on black text for emphasis somewhere, be sure to change to another color pair before issuing a CLEAR command. Note: The ISCOLOR() function will return True on some Mac monochrome monitors. Don't know why. This could make it difficult to write generic color code for all possible machines. 3. Set Intensity ---------------- The SET INTENSITY ON command will cause all GETs on the Mac to execute in white on black which isn't very pleasing. If this command is used in your DOS code, you'll want to comment it out in the Mac version or use it only if the program is not running on the Mac. If you see a sudden change in your GETs to white on black, look for this command or a SET COLOR TO W/? as the culprit. 4. Cursor Control ----------------- The SYS(2002) function which turns the cursor on and off in DOS has no effect in the Mac version. 5. Boxes -------- FoxBASE+/Mac supports both the DOS DOUBLE and BOX commands for drawing boxes, with some odd variations. In general, when you have used either of these commands to draw boxes, you can leave your code unchanged. The DOUBLE command will produce double bordered boxes well, although box intersections show up as three lines rather than two as in DOS. The BOX command is undocumented in the FoxBASE+/Mac manual and produces a single border no matter what characters you originally used in DOS. Here too, box intersections show up differently -- as a double line rather than a single line. If you want to eliminate the different box intersection characteristics, you can place boxes on top of each other rather than "stacking" them. For instance, the code @ 1, 1 TO 15,79 DOUBLE && Stacked boxes @ 15, 1 TO 20,79 DOUBLE will look different on a Mac than: @ 1, 1 TO 20,79 DOUBLE && Overlapping boxes @ 15, 1 TO 20,79 DOUBLE with the latter code producing the "cleaner" appearance. Both code sequences look the same in DOS. If you have drawn a box in DOS and want to divide it from edge to edge with a horizontal or vertical line using the BOX or DOUBLE command, this line will look better on the Mac using BOX than DOUBLE (where the line overlaps the edge on the left or top). Boxes that have been drawn with extended characters do not translate to the Mac. If you use a lot of boxes drawn this way, you may want to investigate the IBMKlone Font which does this job okay. However, it doesn't work quite as well when combined with boxes drawn with BOX and DOUBLE. Other DOS emulating fonts may work better. 6. Extended Characters ---------------------- The Mac extended character set is quite different from the IBM extended character set. Notably, it has far fewer graphics characters. If you have used a lot of extended characters for special effects, you will need to eliminate them, find a Mac equivalent, or use a DOS emulating font which handles them well. The quickest way to handle the problem is simply to eliminate them from your Mac code. This is made simpler if you use the CHR() function in your DOS code rather than typing the character in directly. This way you can do a global search on "CHR(". If you want your Mac and DOS code to handle both cases, you can use the IIF() function: *** the variable MAC is true if running on a Mac *** when there is a Mac equivalent: @ 1,10 SAY IIF(mac,CHR(165),CHR(248)) && produces a bullet *** when there is no Mac equivalent: @ 2,10 SAY IIF(mac,'',CHR(16)) && using null string for Mac According to Fox documentation, even if you use the IBMKlone Font, four characters produce different graphics on the Mac than they do on the PC. These are CHR(8), CHR(9), CHR(10), and CHR(127). Keep an eye out for them. 7. Examples ----------- Examples of the different way the Mac handles boxes and extended characters may be found in the sample program. I. Menus -------- Although my first impression (based on early documentation) was that most FoxBASE+/PC menu options were not supported, eventually it turned out that most of them *were* and, in most cases, supported rather nicely. However, except for the bar-type menu at the top of the screen (READ MENU BAR TO on the PC), these menus are "frowned on" by the interface police who are rather snooty about them, if you ask me. I do not like Mac-style menus. I just plain don't like how they work. If we have time later, you can get me started on this, but now let's keep to business. Here are some basic PC menus and how to deal with them (samples of all menus except "enter choice" are included in the sample program): 1. "Enter Choice" ----------------- This is the old-style menu where you just list choices on the screen and ask the user to enter a number or letter in a GET. Although still serviceable, they were starting to look archaic even on the PC, so they probably ought to be changed sometime anyway. They'll work on the Mac with no changes. 2. @...Menu / Read Menu To -------------------------- For independent popup menus. Although supported, this does not produce the same effect on a Mac as on the PC. On the PC it produces a boxed menu, with optional title, and all menu options showing at once. On the Mac the box is different, the title (if any) does not appear, and only one option shows at first. If you click on this option and pull down, the other options are revealed and stay there until you make a choice. It's kind of cute in it's own way -- but it *is* different from what you'd expect. 3. @...Prompt / Menu To ----------------------- Bar highlight menus. All my PC menus were done this way and I was very relieved to discover that this option was finally supported. I think the Mac version is pretty darned adorable, too, and even more useful than before. When you use the mouse, you see a cute little hand pointing to the options as they're highlighted. Otherwise, the bars work the same with arrow keys. On the PC, the user had only two choices for selecting an option: move bar and press <ENTER> or press the first letter of the option choice. Now, there's an additional option to double click on the option with the mouse (oddly Foxpro only requires one click so moving back and forth between the two can be confusing). 4. Read Menu Bar To ------------------- I didn't find out that this was *in fact* supported until I was working on this presentation and I was annoyed that I didn't know sooner. Not only is it supported, but it also can use almost all the ON MENU options like keyboard shortcuts, and fancy formatting. However, there are a few things to watch out for: * Since the Mac menu bar always includes the Apple menu, the File menu and the Edit menu, you may not be able to include as many options as you can with READ MENU BAR TO on the PC. When translated to the Mac, upper case letters no longer look good in the font that FoxBASE+/Mac uses for this kind of menu. Indeed they take up a lot of space. You can actually get another menu bar option or two simply by changing menu options to capitalized/lower case combinations. * The Mac menus allow all sorts of fancy formatting, separating lines, and the installation of keyboard shortcut keys. The sample program uses all of these. See the instructions for the ON MENU command for how to do this. * The menu is no longer "sticky" -- it won't stay down, but must be pulled down. A return to the menu does not take it back to where it was -- the choice must be made by clicking and pulling all over again. * While on the PC, you could select an option from the drop down menu by pressing the first letter of an option -- that doesn't work any more. You have to make do with "keyboard shortcuts." Unfortunately, there aren't as many available keys because each keyboard shortcut letter can only have one purpose on the entire menu -- not depending on which submenu you're in. * Since the "/" now denotes a hot key or keyboard shortcut, these characters must be removed from any existing choices. * In order to avoid, in any way I can, any possibility of event driven programming, I always turn off the menus before processing any selections with the command MENU OFF [MENU NUMBER] for each menu on the top bar. When this is done, the menu at the top is grayed out. A user can still see what the options are -- they'll just be gray. * The explanatory messages that used to be stored in the top menu item arrays and displayed on the screen, no longer show up at the bottom of the screen. However, one nice thing about this menu on the Mac is that you can put informative comments on the screen. A quick guide to the keyboard shortcuts would probably be appreciated. J. Printing ----------- "Abandon all hope, ye who enter here." Without any doubt, the most difficult thing to convert to a Mac is printing. It is to know the Pit of Despair, the Slough of Despond. As a reference, I figured all this out last November. Then when I was preparing this presentation, I had to figure it out *all over again*. It seems that back in November, I managed to get some things right *completely by accident*. The printing programs in the sample program took me 3 whole days to figure out -- even though I basically knew what I needed to do. So tread warily and hope (knock wood) that your application doesn't have a need for any of the really tricky things. Update note: The primary reason for all this difficulty is that several common PC printing code sequences *do not work* on the Mac and the work arounds are tough. 1. WYSIWYG ---------- Basically, with the Mac, what you see on the screen is what gets printed -- this enables it to print all those fancy fonts and pictures. It also means that you have to be conscious of the interrelationship between what's on the screen and what comes out on paper. Fonts on Screen/Fonts on Paper -- As I discussed in the Screens section, a good font to use on the Mac is nine point Monaco. However, this is smaller than the 10 characters per inch PC standard. Consequently, if you use this as the screen font throughout your program, 80 column reports will not extend across the full width of the page. Similarly, if you need something to print in condensed print, this font will be too big for an 135 column row to print on one line. To adjust the font on the printed page, use the SCREEN command to choose a new *screen* font, perhaps a 12 point Courier. Unfortunately, emulating condensed print is harder. You can set the screen font to a 5 or 6 point Monaco, but this point size will not print very nicely. That is because this particular size of the font doesn't normally come with a Macintosh so the computer "approximates" it, which unpleasant results. The only way around this using standard Mac printing is for you (and your users) to buy a smaller point size of a font for this purpose (you all have to buy the *same* font, too). When you use the SCREEN command to set a printer font, this will also affect anything printed to the screen while it's in effect. You may have to be careful about this. When printing is done, be sure to set the screen font back to the one you want (watch out for printing routine exits). Column Alignment -- When converting from a PC program, I always recommend that you use an fixed-width. If you print with a proportional font (and they *do* look nice), columns may not line up properly, depending on how you wrote your code. With a proportional font, the following code will line up in columns correctly: @ 1,0 say var1 @ 1,10 say var2 @ 1,20 say var3 However, the following code will not: @ 1,0 say var1+' '+var2+' '+var3 2. Set Printer To ----------------- Another vagary of Mac printing is that it will not eject a page until it receives an order to do so. FoxBASE+/Mac documentation says that you must issue a SET PRINTER TO or SET PRINT OFF statement after every printing job where a SET DEVICE TO PRINT or SET PRINT ON statement has been issued. Luckily, I discovered that EJECT works too for standard reports. Really luckily, I discovered that almost all my printing jobs issued explicit ejects. Note: EJECT in DOS works whether the device is set to print or not, but in the Mac, SET DEVICE TO PRINT must be in effect. But say you have a PC program that prints on odd sized forms (postcards, for example). This kind of program would not issue an eject because you don't want the page to advance a full 11 inches after each postcard. One way of handling this in the PC is to have a continuously incrementing counter (so that the counter is never reset to -0-). If you try this on the Mac, none of the postcards will print until you try another printing job or turn off the computer (then they all come pouring out). I don't have any idea where all the information is being kept (I'd have to guess memory), so if it's a lot of data, you might run into other problems. Now, as far as odd sized forms and labels are concerned, I think you can do something with the "Page Size" option in the Mac "File Menu." But I never could figure it out (and I understand it only works with the Imagewriter). It's something I still don't get. If you do manage to figure it out, I think you'll have to stick a SET PRINTER TO or EJECT in after each form, but, again, I don't know. In fact, printing became so totally frustrating, that I completely abandoned standard Mac printing and tried an alternative approach which I'll describe now. 3. Really Irritating Problems ----------------------------- As far as I can tell, there are some printing jobs that simply *cannot* be handled by standard Mac printing. In addition, standard Mac printing is slow by PC standards. My application pours out some huge reports that already may take an hour or more to print, even to a spooler. My users want speed not beauty. So I finally hit upon a way of printing that solved all my needs. Remember this presentation is about PC to Mac conversions. Presumably a lot of the following problems could be handled by redoing everything with the Mac's label and report writers. But that's going to take a lot of time, and, in some cases, *still* won't work. Update note: Although the the label and report writers may work, you should know that you must develop a report form for *each* printer your program may use -- so you may need multiple .FRX files. Note: This discussion is based on an Imagewriter plugged directly into the computer in use -- further fiddling may be necessary for other printers and networks. I've had reports that some programmers have not been able to make this work on non- Imagewriter printers. Update note: As I was working on this part of the presentation for the umpteenth million time, I found out that my approach will not work when printing via network and requires a printer plugged into the local workstation. The two main problems are: * Characters/lines per inch problems, including printing on pre-printed forms where precise placement is a requirement and also including the problem with condensed type. Update note: The reason for this problem is that I was unable to find a font that "comes with" the Mac which places things in exactly the correct place (horizontally *and* vertically) on invoice forms. The Mac's font line spacing is a function of the font size and everything is measured in points, not lines per inch. * "Real Time" printing -- where you want something to print immediately without advancing the page. For example, you might want to print a sample label or form, pause to allow the user to align the forms stock, and resume -- the next line to print must print immediately at the new position. Or you may want to print line by line as the user enters data without advancing the page. I'm going to try to explain these problems, and their solutions, as simply as possible, but it's a very difficult area. Perhaps your best bet is to run the sample program and read the code carefully (I've included additional comments there). But, frankly, all I'm hoping is that I can steer you in approximately the right direction. Override Mac Printing --------------------- In order to solve both these problems, the first step is to override the Mac's printer drivers and communicate directly with the printer. This setup drives the printer directly, like DOS does. This is accomplished by setting the printer to the serial port by issuing the command: SET PRINTER TO COM2 (or COM1) COM2 is the printer port and COM1 is the modem port. Printers can be plugged into either outlet so you need to adjust this command accordingly. Foxbase+/Mac uses the baud, parity, stopbits, databits handshake and endline settings for the Imagewriter as its default. If another printer is used, it may be necessary to specify these settings in the command: SET PRINTER TO COM2 BAUD, PARITY, STOPBITS, DATABITS, ; HANDSHAKE, ENDLINE A sample of this command is included in the sample program. Note: If you use SET PRINTER TO anywhere else in your program to eject a page, you'll overwrite your settings here -- so be careful with it. If an application will be distributed to users with a variety of printers, it may be necessary for you to write a printer set up program for the user to provide your program with the baud rate, etc. plus the proper escape sequences for various tasks (see below) for their printer. This is also handy if you want the user to be able to set the type size within the application (and may be necessary if the user turns off the printer and erases the current setting). Warning!!: If the user *does* turn off the printer in the middle of a print job, characters/lines per inch settings will be erased *and* the "Printer Not Ready Error" will not be triggered as happens in DOS. The Mac will just "print" merrily away until the code runs out. Users might get cranky about this, especially when the Imagewriter eats their invoice forms and they have to wait for "printing" to end as well as start all over again. Characters/Lines Per Inch ------------------------- Once the printer is set to a COM port, the characters per inch and lines per inch settings can be sent directly to the printer using the printer's escape sequences. For the Imagewriter, the following lines of code set the type size to Pica (10 characters per inch) and 6 lines to the inch: SET PRINT ON ?? CHR(27)+"N" ?? CHR(27)+"A" SET PRINT OFF For condensed type (17 characters per inch): SET PRINT ON ?? CHR(27)+"Q" SET PRINT OFF With condensed type there is an additional proviso: the screen font must *still* be changed to a font size that would allow printing a complete row on a page, even though, in this case, the screen font has no effect on the size or appearance of what actually prints (does this drive you crazy or what?) I use 4 point Monaco. Update note: This problem with condensed type also applies when printing to a *file*. Real Time Printing ------------------ First the problem: when using PC code and Mac standard printing, the Mac will not simply print one form (label, invoice, etc.) and allow the user to pause and realign the forms stock. For example, the following code, using the ? command, is common: SET PRINT ON ? "This was printed using ?" SET PRINT OFF In standard Mac printing, this will print a label and eject the page. The following code, using the @..SAY command is also common: SET DEVICE TO PRINT @ PROW(),1 SAY "This was printed using @ SAY" SET DEVICE TO SCREEN This won't print anything on the printer -- it's stored somewhere awaiting a SET PRINT TO or EJECT command, which when received, will again eject the whole page. However, by setting the printer to the COM port and fiddling with the code, you can produce the effect you want. The following code does this (it's from the sample program): *** using the ? command set print on ?? 'This was printed using ?' ? 'line2' ? 'line3' ? 'line4' ? 'line5' ? 'line6' set print off *** pause to allow user to align the form CNTR=1 do while CNTR<=15 set print on if MMAC pcol=0 ?? 'This was printed using?' && The reason for this code on && the Mac is a little difficult && to explain. OK, I don't *know* && why it works, it just does and && at this point I don't care && anymore. So sue me. else ? 'This was printed using ?' endif ? 'line2' ? 'line3' ? 'line4' ? 'line5' ? 'line6' CNTR=CNTR+1 set print off enddo *** using @..SAY set device to print set print on store 0 to CNTR2 @ CNTR2,0 say 'This was printed using @ SAY' @ CNTR2+1, 0 say 'line2' @ CNTR2+2, 0 say 'line3' @ CNTR2+3, 0 say 'line4' @ CNTR2+4, 0 say 'line5' @ CNTR2+5, 0 say 'line6' ? if MMAC CNTR2=0 && with incrementing counters on && the Mac reset counter to 0 && each time else CNTR2=CNTR2+6 endif set device to screen && the SET DEVICE TO SCREEN and set print off && SET PRINT OFF commands must be && exactly in this order to work *** pause for user to align forms if .not. MMAC set console off && saves screen scrolling on the PC endif store 1 to CNTR do while CNTR<=15 set device to print && both these commands are necessary set print on && for Mac to allow use of ? @ CNTR2,0 say 'This was printed using @ SAY' @ CNTR2+1, 0 say 'line2' @ CNTR2+2, 0 say 'line3' @ CNTR2+3, 0 say 'line4' @ CNTR2+4, 0 say 'line5' @ CNTR2+5, 0 say 'line6' ? CNTR=CNTR+1 if MMAC CNTR2=0 && because prow() = 0 else CNTR2=CNTR2+6 endif && for real time printing: set device to screen && <=both these commands are set print off && <=necessary and exactly in this && order even if you aren't && returning to the screen at this && moment enddo set console on Three things to note: -- First, if you use incrementing counters, as in the example immediately above, you will need to reset the counter to 0 before printing the next label since PROW() is reset to 0 each time. Second, if an address does not take up the entire label (say it's only 4 lines long), you will need to position the printer at the last row of the label, either by issuing additional ? commands or saying @ cntr+5, 28 SAY "" (before issuing the ? command). Update note: In DOS you can produce blank lines with the ? command. Three ? commands will produce 3 blank lines -- on the Mac they produce only *one*. To make this work, you need to change the command to ? " ". Third, the SET DEVICE TO SCREEN and SET PRINT OFF commands must be issued in exactly that order to work. Similar code will also handle odd page lengths. In my case, I needed to print on an invoice form that was 7 inches long -- 42 rows (rows 0 through 41). Here again it is necessary to issue an @ SAY to position the printer at the last row of the form before issuing ?? (or ?): SET DEVICE TO PRINT SET PRINT ON cntr=0 @ cntr+1,1 SAY "INVOICE ELEMENT" && 7 inch form @ cntr+2,1 SAY "INVOICE ELEMENT" && 6 lines/inch @ cntr+3,1 SAY "INVOICE ELEMENT" && rows 0-42 [additional commands] @ cntr+41,1 say " " && position the printer && on last line of form ?? && ?? works like ? SET DEVICE TO SCREEN SET PRINT OFF Once again, for a demonstration of these concepts and additional comments, see the sample program. IV. EASY MAC-LOOK ENHANCEMENTS ============================== Once you've dealt with all the preceding details and *if* you have the strength left, there are several easy things you can do to make your program more Mac-like. 1. Help ------- Probably one of the nicest things you could do is to substitute FoxBASE+/Mac's on line help for the way you do help now. However, this can be very tedious if your help is hardcoded (mine was). Personally, I'm developing this kind of help in Foxpro and will port it to the Mac when the time comes. If you don't use Mac help, you should SET HELP OFF in your program so that nothing will happen if the user chooses this option from the Apple menu. 2. About Your Program --------------------- It would be nice to replace the "About FoxBASE+" option in the Apple menu with an "About Your Program" option. However, this does not seem possible if you're using DOS based menus. However, you *can* make the "About FoxBASE+" message disappear. Indeed, you can disable the entire Apple menu if you want to. See sample program for how this works. 3. Alerts --------- Alerts are really easy to program and add a nice touch. See sample program and Commands and Functions manual. 4. Wait ------- On the PC, the default message for a WAIT command is "Press any key to continue." On the Mac it's "Waiting" which I don't like as much. You might want to initialize a WAIT prompt in your code and use it whenever you use a WAIT. See sample program -- in the Screen Examples procedure, you can see the waiting message change. 5. Mouse vs Keyboard -------------------- Although the Mac is very mouse oriented, people still have to enter data with their fingers. That's one of the reasons I don't like Mac menus. I try to set up a program so that it can be just as easily navigated via the keyboard as with the mouse. And I find that for some tasks, like selecting reports to print, I use the mouse, and for other tasks, like adding accounts, I prefer to navigate continuously with the keyboard. From a PC perspective, don't forget about mouse navigation. Although I didn't really deal with this well in my conversion, it should be possible for users to choose as many options as possible with a mouse *as well* as the keyboard. Look especially for areas (like report printing) where the mouse might be the easiest tool, and make changes there first. V. MISCELLANEOUS CONSIDERATIONS =============================== Testing -- Although it's the last thing you want to do, I'd advise testing *everything* in your program again once the Mac conversion is complete. I discovered all sorts of little odds and ends (which you now know about) in the process. It's entirely possible that there are some quirks that I didn't find (and I was finding quirks right up to the last minute while preparing this presentation). Caveat developer. Distribution -- Obviously, PC batch files don't work anymore for automatic installation purposes. There isn't, as far as I've found, a Mac equivalent. STUFFIT is the Mac equivalent for PKZip and there are two self-installing utilities available. I haven't had time to experiment with these, but Foxbase+/Mac uses a variation of this software to install itself. Preparing a runtime application is a little tricky. You can read up on it in the Users Guide. Documentation -- Is, as usual, a pain. Since with a basic conversion, you won't be changing the screen appearances too much, most of your PC documentation will work as is. However, I had to write new installation instructions, change a few screen shots (especially where editing memo fields was concerned), and add on some information about using the mouse etc. Screen shots were kind of nice. On the Plus, by pressing Command-Shift-3 (with Caps Lock on), a picture of the screen is saved in Mac Paint format on the hard disk. These pictures are called Screen 0, Screen 1, etc. in the order they're produced. I was able to port them over to the PC and load them straight into Ventura. Piece of cake! Unfortunately, they made my old PC screens look kind of anemic. VI. OTHER TOPICS ================ Backward Compatibility -- Compatibility backward from the Mac to the PC is a little difficult at this time -- but I have reason to believe that will change as Foxpro handles more and more of the Mac commands. * Unsupported commands and functions -- With FoxBASE+, there are a lot of Mac commands that aren't supported on the PC, notably the ones that generate radio buttons and such, but also such basics as SCREEN. In order to port to the PC, you'd have to make a very thorough analysis of what's available *on* the PC. * Form design -- Definitely the only way to go in designing screens for the Mac is the Mac's forms design feature. You can use it to produce a format file and then integrate it into your program. Unfortunately, it does *not* have a character based option and figures everything out in pixels which won't work on the PC. It also generates a very great deal of extraneous code (in most situations) that will quickly bulk up your application if you don't strip it out (which is tiresome). There are some examples of the code it produces in the sample program. * Dos file conventions -- when developing on the Mac, use Dos file conventions. * Path/file naming -- watch out for colons in your path names or searching for colons in path names for certain purposes. * The Future -- FoxPro/Mac. You probably know as much about this as I do. I think that FoxPro and FoxPro/Mac will become very close with each one supporting the command sets of the other. We will have to see, otherwise I'm going to end up making a career out of this presentation and I'd just as soon be programming instead. There are some products available now, notably Code in a Flash by Flash Creative Mangement that will write your screen code in either Mac or FoxPro at, I'm told, the touch of a button. Y. Alan Griver will gladly fill you in on this. The Sample Program -- The sample program -- PC2MAC.PRG -- is written to run on either a PC or a Mac and to demonstrate the topics that have been discussed in this presentation. Menus, screen examples, and printing are included plus little odds and ends that were fun to throw in. The code is heavily commented and touches on one or two points not covered here.